@complexspaces WDYT about rebasing this and merging it as-is (maybe modulo the small fixes called out by tshepang)? I think my feedback about more documentation for the release process doesn't need to be blocking. We could iterate on those parts based on experience.

@complexspaces small bump. Would it be helpful if I rebased this branch and addressed tshepang's comments?

Hi, sorry for the delay @cpu. I've once again gotten behind on things. I will address tshepang's comments this week and try to clean up some of the other smaller comments as well before Monday next week. At that point, we can evaluate if this looks good enough for an initial publishing attempt?

I will address tshepang's comments this week and try to clean up some of the other smaller comments as well before Monday next week.

Great, thank you! I know it's a busy time of year :-)

At that point, we can evaluate if this looks good enough for an initial publishing attempt?

Sounds good to me. I'm eager to get something out into the world before the new year if we can convince ourselves that all of our ducks are in a row. It might be nice to land #42 but it seems unlikely that Reqwest and the other blocking dependencies will be ready on a short timescale. The very recent Hyper 1.0 update layers a bit more complication into the mix.

Checking in again: anything I can do to help move closer to publishing a release?

Here's an updated branch that's been rebased on main and had the majority of the outstanding review feedback addressed. I could force push it onto this branch, or open a new PR as folks prefer.

I believe that I've finished this branch and it's ready for another review. It took a bit longer then expected (1-2 days last week), and I apologize for the inconsistency. I ended up needing to port the .gradle script examples to Kotlin in order to end-to-end test the release/dependency process. 1Password internally moved to .gradle.kts files, and that was also my "test user" project :)

In the extra time I also discovered some Gradle performance/correctness improvements as well so IMO the initial release will be more polished as a result.

New changes include:

• Fixing up the typos that were pointed out, and more I noticed after temporarily enabling a spellchecker.
• Cherry-picking in and then squashing @cpu's release documentation suggestions.
• Resolving the last of the threads I believed were important (notably the context around --allow-dirty, and documenting a future TODO that may remove the need for it so no one forgets)
• Updating the Gradle integration example to remove the hacky Memoize usage and instead place the Maven repository definition in the right place.
  • This saves on configuration time and ensures the script is only run once the Gradle-intended way 😅.
• Documented intended Gradle sync performance/behavior so regressions have a baseline to report against.
• Added steps for verifying the rustls-platform-verifier-android dry-run package both on the filesystem and inside a Gradle project for testing.

Using all of the now-documented steps, I tested a few things to build confidence in the first release we make:

• The Gradle integration is working as expected WRT caching and version updates (using a filesystem rustls-platform-verifier dependency patch)
• Filesystem crate patches are recognized for local development/overrides in both Cargo and Gradle.
• The extracted dry-run crate package is recognized by Gradle as well.